初始設定

一開始我們就在 Azure 租一個 node ， 程式後端（以下稱API)、Nginx、MongoDB 都在裡面，完全是輕輕鬆鬆的會發生 single point of failure
後來發現這樣，要 deploy 後端程式時候，就要把服務暫停才行。所以就把 API 跟 MongoDB 拆開，然後多加了幾個 API 的 instance。

第一次遇到問題：太會聊天

本來因為 array 很方便，我們本來就開了一個儲存對話的 collection，兩個人間的對話就是一個 document。後來開始有人越用越多後，才發現一個 document 的大小有上限 (16M)，居然有人可以聊到達到這個上限。雖然算是 corner case，但也讓我們發現目前的 schema 不可行，於是存對話的部分，改成了一個新的 collection，一個 document 就是一個訊息加上一個對話 ID。

第二次遇到問題：out of memory

後端跟資料庫分開後，資料庫這邊維持現狀好一陣子。
後來用戶又持續增長，效能開始出問題後，就開始研究要怎麼不用花太多錢改善效能。這也是有錢大公司跟沒錢小團隊的最大差別。畢竟現在都是 host 在雲端，只要有錢，按幾個鍵提升主機的規格，效能馬上改善。

雖然透過增加 index 可以改善，但我們遇到一個問題是，尖峰時段 MongoDB 會用超過 VM 的可用 memory (Out of memory) ，此時就會慢到不行，也就只好認明提升 instance 的規格。我們每次都是出事了才提升規格，目前已經改了好幾次。難以想像以前要自己在辦公室放主機的時代要多麻煩，哈哈。

第三次改善

後來看了 Mongo 官方建議。發現推薦的形式是要有至少三個 instance: primary、replica、arbiter。
我們才加到三個 insance。這也讓我們大幅降低跟資料庫有關的 downtime。

光是 mongo 就好多可以寫，哈哈。下次寫最終形態的改善。

最新文章會分享在臉書：https://www.facebook.com/gigi.wuwu/
歡迎留言討論